The rapid emergence of Internet applications based on multi-tier architectures with componentized code has created a need for heightened computer security. That is, software applications are no longer stored in and executed from a single monolithic file. Instead, applications are created from multiple components, potentially running on multiple machines, and delivered and executed across multiple networks. As computer systems increasingly rely on these distributed system and network architectures, computer software must increasingly protect secrets critical to the application's functionality, including cryptographic keying material, passwords, and message digests (or hashes) used to verify the integrity and authenticity of one piece of computer software to another.
For example, with reference to FIG. 3, a server 301 running internet web server software (e.g., Internet Information Server) communicates with local client machines 303-309, each running a web browser (e.g., Microsoft Internet Explorer®). In many cases the client needs to know it is talking with the right web server before providing payment information for an electronic purchase. Typically, this is handled by creating a secure SSL communications channel with server authentication. This creates a problem for the developer of the Internet web server software. SSL authentication requires storage of a private cryptographic key for this purpose, along with a public server X509 certificate. This private key needs to be kept hidden and only made available for use in Internet web service authentication. If a hostile entity can compromise this key, they can impersonate the service and potentially cause significant harm to the clients and to the service owner's business. However, current operating systems and virtual machine environments do not support hiding such secrets such that only a single application can use them. The result is that each application developer must come up with his or her own approach to hiding such secrets or accept a potentially serious risk that must be mitigated using deployment and administrative procedures.
Known solutions to protecting application secrets have focused on protection of persistent data on a per-machine or per-account basis, and isolating runtime information and code at the process level. These solutions typically encrypt an application's secrets using a unique machine key protected by the operating system, or a user-specific key derived from the authentication credentials of each user. In the first case, any application code running on the machine can access the secrets; in the latter any application code running on behalf of the user can access the secrets. If an application has secrets that it truly needs to protect from other application code, it is necessary to implement some private method of hiding such secrets. Approaches that have been used include use of a password derived cryptographic key to encrypt the secrets, scatter-gather algorithms to try and hide such secrets in the application, and use of algorithmic approaches to materializing the secret value when needed. The first method is often impractical as it requires an authorized user be present to enter the password when the secrets are needed. The last approach often results in weak protection as such algorithms are difficult to design and implement in ways that are not trivially attacked.
The difficulty of attacking a secret hiding algorithm is generally determined by the difficulty level of reverse engineering the algorithm used. Design of these algorithms, such that they are not easily reverse engineered, is difficult as the hacker has complete access to the application code. If a hacker can determine how such an algorithm works, then the secrets can be easily retrieved by hostile code. Such code also impacts the application developer in that it requires additional development and debugging time impacting the overall cost in creating the application.
Previous solutions also do not provide a mechanism by which trusted code components can securely share information when they are running inside the same process space with less trusted code components.
Because of the aforementioned difficulties, typically only large developers of high-end services such as Web servers (e.g., IIS), mail servers (e.g., Exchange), or authentication servers (e.g., Kerberos KDC) have been able to expend the resources to develop proprietary solutions based on careful design considerations, after substantial development time, and having undergone rigorous testing to avoid unintentional security breaches. Such solutions are often cost prohibitive for software developers with more modest budgets, causing smaller developers to use less secure methods for protecting application secrets. However, software developers of all sizes require the protection of application secrets to meet their customers' needs.
There are many known examples of solutions used by smaller developers including: storing application secrets (e.g., login/password pairs) as encrypted strings in data files, typically offering minimal security; storing application secrets as clear-text strings in resource or configuration data, which provides virtually no security; and simplistic algorithms that simply write the secret into the application code's data areas at some reserved offset. These known solutions do not provide a general solution that developers can use to manage application secrets with robust security.
Thus, it would be an advancement in the art to be able to more effectively protect critical application secrets in a form that prevents disclosure to potentially hostile code on the same machine, while allowing easy retrieval by the owning application. It would also be an advancement in the art to make such a solution available for arbitrary applications to use through a well-known application program interface (API). It would be a further advancement in the art to be able to protect an application secret when sending the secret to another trusted application, without allowing untrusted applications or malicious code to also access the secret.